\section{Conclusions}
	\subsection{Integration}
	
Contrary to popular belief, integration is easy. At least, thanks to ROS, integration was mostly a matter of determining which information was required by each component, and then agreeing on a common message definition to provide that information. The modular design enforced by ROS allowed us to write simple nodes, test them against a virtual, simulated environment, and work independently of other components while still enabling more or less seamless integration.

Thus it was for example that we could just as easily run our exploration phase with manual control, switch halfway through to automatic control, return the robot to its starting position and then let the navigation system find its way to each tag previously encountered. Thus it was that work on obstacle avoidance began long before the IR sensors were capable of publishing accurate distance estimates, while performing just as well in the real world after they were up and running. Likewise, the map could store the position of tags just fine, long before the camera node had been completed. When it finally was completed several weeks later (or at least, when it performed adequately for the task it was designed for), combining it with the already existing functionality to mark tags on the map worked without a hitch.

All this was to a very large extend thanks to the ROS infrastructure. That is not to say that ROS is not a mixed blessing: we found that even a completely empty node had a memory footprint of at least 10 megabytes. Communication appeared fast, but merely printing out info messages already stressed the CPU. In short, ROS helps, but at a significant cost. 

	\subsection{Goal Performance}
How well did we do on the goal? As already discussed in section \ref{sec:analysis_bottlenecks}, most of our components worked quite well, and the robots overall architecture, both in hardware and software, seemed to perform to expectations. So we are left to resign ourselves with could-have-beens: if our particle filter had performed as expected, our maps would be better. If the camera node would have 100\% tag identification performance, the tag score would have been better. If we had worked on our exploration behavior earlier and more extensively, we would have been able to map the entire maze. 

The robot then works well if considered a proof-of-concept: everything we did, barring a few development dead ends, worked. Continuing development will almost certainly yield a flexible robot, capable of performing the tagging task well, thanks to a carefully constructed SLAM algorithm, robust hardware, and flexible behaviors. In practice, our proof of concept needs much, much more refinement. It is a coarse approximation to what it could have become with more work, performing poorly on the task set for it when development stopped. But we know where our bottlenecks are, we know where more refinement is needed, and we feel confident that our robot is well designed, well build, and quite close to being amazing.